Issues of Visualized Conflict Resolution

Effective and efficient requirements negotiation is a key to the success of software development efforts. For large projects, this can be especially difficult to do effectively and efficiently when combining input from non-co-located experts and reaching consensus among the different stakeholders (e.g., end-users, developers, software assurance, customers) as well as among the different aspects of software requirements (e.g., functionality, nonfunctional quality, and infrastructure). Stakeholder perception conflicts about requirements issues should be identified and resolved in early stage of the project lifecycle to achieve a shared vision of the requirements. In this poster, we discuss the issues and potential solution approaches for software requirements negotiation problems through visualization. The representation of stakeholder perceptions, visualization of the perceptions, and conflict identification and resolution in the visualized perceptions are discussed. Context and Motivation Effective requirements negotiation among stakeholders at an early stage of software life cycle is a key factor of successful software projects. In order to effectively support requirements negotiation, the WinWin system and tradeoff analysis tools were developed to assist stakeholders to elicit their win conditions (initial objectives/requirements), identify conflicts among the win conditions, generate options to resolve the conflicts, and reach agreement by iterating, rejecting, and negotiating the options. WinWin has been successfully applied to requirements negotiation of small projects such as USC Software Engineering classes (1996-2000). However, if the number of stakeholders and/or options increase (e.g., in large scale projects), we have experienced the following challenges to reach agreement from options among stakeholders: (1) Representing and understanding the different perceptions of multi-disciplinary stakeholders in order to evaluate options (2) Communication overhead of negotiating options grows at the rate of O(n), arising from increasing numbers of stakeholders and options (e.g., if one stakeholder negotiates each option with another stakeholder, n! one-to-one negotiation would take in place). (3) Distributed and asynchronous environment makes negotiation much harder because people cannot use the many cues they get from being in the same room together at the same time. Distributed Collaboration Priorities Tool (DCPT) [1] has been proposed to support collaborative prioritization of decision items (options) to overcome the above challenges with visualization aids. Perceptions of each decision item per stakeholder are visualized in 2D graphs with Difficulty and Importance criteria. The items are classified and prioritized on the basis of perceptions. For example, items with high Importance and low Difficulty could have higher priority than those with low Importance and high Difficulty. Our experiment to apply DCPT to a NASA IV&V project showed that visualized perception serves as a common and effective language for understanding and communication between stakeholders. It also accelerates the priority negotiation process by providing collaborative tool support, even in a distributed, asynchronous environment. However, DCPT does not effectively support more complicated situations when evaluating more than two criteria and needing more sophisticated visualization and more powerful analysis (e.g., group clustering, stakeholder profile analysis). In this poster, several visualization issues of conflict resolution support for software requirements negotiation are discussed based on our experience and findings when applying DCPT to a real-world project in the NASA IV&V Facility. With discussion of the issues, this poster also briefly explores potential solution approaches to semi-automatically identify and resolve the conflicts. How to Represent Stakeholders’ Perception? How to Measure the Degree of Consensus? In the WinWin context, several options to resolve issues are explored and evaluated by stakeholders. Each stakeholder may have different perceptions regarding evaluation criteria for issues. To reach agreement, these different perceptions should be explicitly represented and compared with others. The perceptions may also be adjusted to reach consensus. How could the perception be represented? How could the degree of consensus among stakeholders in terms of represented perception be Proceedings of the Fifth International Symposium on Requirements Engineering (RE’01) 1090-705X/01 $10.00 © 2001 IEEE 2 represented? Questions such as these are important because they help identify and resolve conflicts based on perception representation and consensus measurement. Specific terms and definitions to help define “consensus” are: • Stakeholders (S1, S2,, ..., Si), are any individuals or entities participating in the decision making process. • Decision Items (D1, D2,, ..., Dj), are requirements issues to be agreed upon by stakeholders. • Criteria (C1, C2,..., Ck), represent several decision criteria to evaluate Decision Item, Dj. Each of these criteria have logically different relationships with the decision item. • Vote Vijk , represents a Stakeholder Si’s vote on Criteria Ck for decision item Dj. A “Vote” could be a measure of the stakeholder’s perception for evaluating a decision item in terms of a criterion. Generally, the Vijk domain could be normalized from 0 to 1 or from 0 to 10. A degree of consensus between stakeholders m and n , called “Consensus Factor, CFj (m,n)”, about Decision Item Dj for all its criteria between stakeholders m and n can be defined as follows: _____________ Cfj (m,n) = √ Σ (Vm j k Vn jk ) k CFx (m,n) > CFy (m,n) means that stakeholders m and n have more consensus on Decision Item Y than Decision Item X. CFx (m,n) > CFx (m,l) also means that stakeholders m and n have more consensus on Decision Item X than stakeholders m and l have. Thresholds can be defined for such measures to identify whether we have a situation of complete or partial agreement. Suppose ‘CFj’ represents a consensus factor on Decision Item Dj for all criteria. We can classify three (or more than three) groups based on CFj as follows: • β < CFj <= χ Complete Agreement • α < CFj < = β Partial Agreement • CFj < α No Agreement Determining thresholds such as α, β, χ could be dependent on domain, situation, and organization. How to Visualize Stakeholders’ Perceptions? The visualization process helps the stakeholders to effectively assimilate complex data sets and focus on important implications. The graph reveals, at a glance, the positions of all the stakeholders as well as conflict in perceptions. DCPT visualizes the pair-wise voting result of each stakeholder for each decision item in the 2D graph with Importance and Difficulty criteria. However, how could the stakeholders’ perceptions be visualized in a scalable way if each decision item has more than two criteria? How to Identify Key Conflicts in Visualized Perceptions? Any single quantitative measure of existing conflict (e.g., consensus factor) is not sufficient to convey the full implication of the relative positions of the stakeholders. We may have situations, which are widely different in reality, for which the consensus factor is similar. Visualization of perceptions provides an intuitive way to identify conflicts. However, is there a systematic way to identify key conflicts? A systematic approach to identify key conflicts is stakeholder profile analysis. All stakeholders in a collaborative group do not have the same expertise or experience regarding the issues being discussed. Based on profiles of each stakeholder, commonality and differences between stakeholders in each group who have the same or similar positions can be analyzed. In some cases, there is a general agreement among the majority of the stakeholders. The few stakeholders whose opinions differ from the majority are referred to as “key contenders”. These stakeholders have the most divergent opinions in the group. Thus, it is imperative to identify such stakeholders who can either revise their position or annotate their vote accordingly. An arbitrator, on behalf of a group, can choose to ignore a vote for evolution of consensus if it is allowed by the profile of the stakeholder 2.4 How to Resolve Conflicts Using the Visualized Perceptions? Several clustered groups who have the same or similar consensus were identified in a NASA IV&V experiment. The finding, as a result of profile analysis, was that the stakeholders in the clustered group belonged to the same organization. How could the conflicts of the clustered groups be resolved? Key contenders, who differ widely from the majority, may have to be focused to effectively resolve the conflicts. They may have different evaluation methods or models, different understanding of issues and options, or special expertise that differs from other stakeholders. From a risk management viewpoint, discussion between key contenders and others is important.